Loadstar 242/242.d81/t.real sounds

Text File | 2004-01-01 | 7.5 KB | 284 lines

u
        R E A L   S O U N D S

  Sounds edited by William O. Nelson

      Text by Jeffrey L. Jones


    Here we have a collection of
sounds in BASIC that mimic things you
would find in real life. William
Nelson has taken them from the
hundreds of programs he's seen over
the past ten years. Some of these
sounds are amazing, not that they
sound out of this world because
actually they're pretty BASIC (pardon
the double entendre). They're amazing
in that some of them are as short as
one line -- and they [work]! That's
taught me something!

    I've worked with sound very
little in my tenure (actually
elevenure) as a Commodore programmer.
That's because I've written very few
games. I did submit a pitiful game
called "Star Guard" way back in 1988.
Fender accepted it, he may have even
paid me for it, but could never bring
himself to publish it. I also added
bleeps and buzzes to JEFF'S TOP TEN,
which ran a couple of times in the
60-something era of LOADSTAR. Had I
known that adding a sound could be
this simple, my programs would have
had more sound in them all this
time.

    None of the sounds have the same
line numbers. None of the sounds
take up more than a screen. If you
have JiffyDOS, all you'll have to do
is enter:

  [@d:sound name]

 to list the file to the screen and
then just hit RETURN over the lines
to add them to your program. Make
sure your program doesn't have the
same line numbers.


 IF YOU DON'T HAVE JIFFYDOS
 {SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}

    If you don't have JiffyDOS, the
easiest way to do it, short of
printing and typing the codes is to
first LOAD the sound and LIST it.
Most of the sounds fit on one screen.
Next move the cursor up to just below
the last line LISTed.  Now LOAD your
program and then hit RETURN over
the sound lines to add them to your
program. Hopefully, none of the
lines have scrolled off the screen.
I did write an appender program which
is on THE COMPLEAT PROGRAMMER that
will append higher numbered programs
to your programs.


 SOUND AND TIME
 EXCERPTS FROM LOADSTAR LETTER #33
 {SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}

    If the sound of a tree falling in
the woods lasted for only a 20th of a
second, would anyone hear it?
Probably not.

    Einstein said it best, "The amount
of time that a sound resonates is
usually based on a crude FOR-NEXT
loop." Okay, maybe Einstein never said
that, but he understood relativity,
and time is very relative in a
FOR-NEXT loop. Compile or accelerate
that FOR-NEXT loop and it's suddenly
taking much less time to execute. And
when your sounds are perfectly timed
to exist for a certain number of
moments, they become different or even
inappropriate sounds when their gate
(sounding) is shortened. Cut a bell by
four and it becomes a blip. By 20?
Accelerate [and] compile? That may be
more than 400 times faster! Your bell
sound might not even make a click!


 GETTING THE DELAY YOU WANT
 {SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}

   TI is a system variable, and it
changes every 60th of a second.
Using it, the obvious way to delay
for a half second is to count off 30
jiffies:

 100 TQ = TI
 110 IF TI < TQ+30 THEN 110

    Need a quarter second? Test for
less than tq+15. Need 3 seconds? Try
TQ+180.

    If more games had lines like these
instead of arbitrary FOR-NEXT loops,
they would run perfectly on all
systems. The above code will wait for
a half second, compiled or uncompiled,
accelerated or unaccelerated, or any
combination thereof -- with any type
of accelerator.

    When your perfectly timed sound is
compiled or accelerated, you may run
into timing problems. Fortunately the
average delay loop,

       [FOR D= 1 TO 1000:NEXT]

isn't sped up much by normal
compiling.  Here's a comparison chart
for the code:

 10 A=TI
 20 FORI=1TO2000:NEXT
 30 PRINTTI-A


 Uncompiled:                124
 Blitz!:                     96
 Abacus Compiler 1 P-code:  116
 Abacus Compiler #1 M-code: 112
 Abacus Compiler #2:P-code:  30
 Abacus Compiler #2:M-code:  30

    Note that I had originally tested
a program that counted to 1000, but
realized that on a CMD accelerated
system with Abacus compiler #2, less
than one jiffy would accumulate. Since
we need at least one jiffy for testing
purposes, I doubled all the numbers.

    Given that it will always take a
normal C-64 124 jiffies to count to
2000, we can use the loop as a test
during program setup and come up with
a factor, [F], with which we can
equalize all subsequent delay loops.

    For instance if we're running a
Blitz! compiled program on a CMD 20MHZ
accelerated system, the loop will
probably take 96/20 or 4.8 jiffies (we
don't have the accelerator yet). I'm
dividing by 20 since the accelerated
program will run 20 times faster. In
our test loop, it will probably come
out to 4 jiffies even. Since our
standard is 124 jiffies for this loop,
we take 124 and divide it by 4 and
come up with a factor of 31. So all
delay loops in that compiled and
accelerated program should be
multiplied by a factor of 31. Here is
how the factor routine would look:

 3000 F = TI
 3010 FORI=1TO2000:NEXT
 3020 F = TI - F
 3030 IF F = TI THEN F = 1 : RETURN
 3040 F = 124 / F : RETURN

    Line 3030 exists because the jiffy
clock might be off for some reason --
you may have previously disabled the
STOP key with POKE 788,52. In that
case, you can't know how many jiffies
have passed so your factor will have
to be one. I suggest enabling the STOP
key with POKE 788,49 during the test.

    Now that F is defined, we can
insert it in all FOR-NEXT type delay
loops:

        FOR I=1 TO 500*F:NEXT

will run at roughly the same speed,
compiled or uncompiled, accelerated or
unaccelerated, or any combination
thereof. Even if your C-64 were
running a little slow for some reason,
the delay would be the same.


 FINAL NOTES
 {SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}

    You can apply this scheme to the
sounds supplied under this heading if
you choose. I didn't include a
factor in the routines since it would
make all delays nil unless you first
define F as 1 and I didn't want to
lock you into it. That would make me
a bit overbearing, wouldn't it? But
we do ask that you use such a scheme
if you submit a program with sound to
LOADSTAR. We do want our programs to
work satisfactorily on all systems.


 [FENDER'S POSTMUMBLE:] At first I
asked Jeff to convert all of the delay
loops from the FOR-NEXT format to the
TQ=TI format, but then he brought up
the fact that if the STOP key had been
disabled by POKEing 788 the TQ=TI
method won't work -- unless you
re-enable the STOP key right before
the delay and then disable it again
right after.

 But I wanted to see how much work was
involved, so I converted the first
three sounds. It wasn't hard.

 This accelerator/STOP key problem is
typical in programming. Everything has
a DOWN side as well as an UP side.
This is the problem in a nutshell. If
you:

 POKE788,52 to disable the STOP key,
the TQ=TI method won't work.

 POKE808,239 to disable the STOP key,
BSAVEing and BLOADing might not work.

 Use FOR-NEXT delay loops, your
program won't work right on an
accellerated system.

 In my opinion, the TQ=TI method is
best for delay loops and as for
disabling the STOP key, I'm coming
around to Jeff's opinion that the STOP
key doesn't have to be disabled. I
have to admit it's been years since I
accidentally hit the STOP key. And
anyway, all you probably have to do is
enter CONT:REM and the program will
continue.

 I guess at the bottom of my thinking
is: how many programs are so important
that an accidental STOP should cause
dismay? I work on Commodore programs
all day long five days a week and if
occasional blips caused me as much
concern as they seem to cause some
people I'd figure it's time to look
into some other way of making a
living.

 FT